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ABSTRACT 


This is a technical report on the results of a one-year contract to study 
the application of techniques for real-time computer generation of tele- 
vision images to the visual display of a Lunar Surface Roving Vehicle 
(LSRV) Simulator at National Aeronautics and Space Administration, Marshall 
Space Flight Center (NASA, MSFC) . Many of the techniques herein have been 
known to simulation system designers for some time. This report outlines 
a system that combines known techniques of data representation and hybrid 
(analog-digital) computation with^some very powerful and novel methods of 
electronic image synthesis. Although the techniques are specifically 
applied to the LSRV simulator, they are also useful in many other types 
of real-time display generation. The Appendix to this report includes 
the results of an effort to simulate in non-real- time the type of out- 
the-window displays which might be produced by the techniques described 
in this report. 
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COMPUTER GENERATION 
OF TELEVISION IMAGES : 
REAL-TIME SIMULATION 
OF LUNAR LANDSCAPE DISPLAYS (U) 


I. INTRODUCTION 

An important part of many real-time vehicle simulators is the visual 
display which provides the operator with a simulated out-the-window view 
of the vehicle’s environment. Indeed, the visual display is often the most 
difficult and costly portion of a simulator. This is particularly true for 
the Lunar Surface Roving Vehicle (LSRV) Simulator being developed by NASA 
at Marshall Space Flight Center (MSFC) . The present report develops the 
requirements for a digitally controlled out-the-window display and means 
of implementing it by use of electronic, as opposed to physical, models. 

In the past, the basis of such visual displays has been a TV camera- 
model system in which a TV camera, mounted on a movable gantry, views a 
painted, photographic, and/or relief model of the vehicle's environment. 

NASA’ s present Lunar Surface Roving Vehicle (LSRV) Simulator, a modified 
SMK-23, is of this type. Specifically, the SMK-23 uses a 3" image orthicon 
camera and a rubber relief map of a portion of the lunar surface. The 
camera is located over the model by servos which are controlled by analog 
computers. The input to the computers is a set of terrain sensors which 
detect the height and slope of the terrain at the position of the vehicle. 

The limitations and drawbacks of simulators based on a physical model 
are immediately apparent. First of all, they are very cumbersome and re- 
quire a considerable amount of space. For example, at a scale of 150 to 1 
a square mile of terrain requires a 35 foot square model. Next, the speed 
and acceleration which can he simulated are limited by the speed and strength 
of the servos which position the TV camera. Also, there are many limitations 
in the TV system, for example, resolution, depth of field, adequate lighting, 
noise, etc. Finally, they are susceptible to the failure of their numerous 
mechanical parts. Because of these limitations, methods were sought to re- 
place the physical model with a mathematical model in a computer. 



Early attempts at computer image generation in real-time were, how- 
ever, limited to producing pictures which were composites of simple geo- 
metric shapes described by either vectors or elementary functions. Although 
it has also been possible with a computer to enhance single frames obtained 
by photographic processes, this is presently not practical in real-time. 

Recently, Pennsylvania Research Associates Inc. (IRA), under con- 
tract to the Naval Training Device Center (NTDC), has developed methods of 
producing real-time, computer-generated TV images which have grey scale 
and texture rather than solid, geometric shapes. These images are produced 
by special-purpose hybrid* computing equipment under the control of a gen- 
eral-purpose digital computer. At the present time, NTDC is constructing 
a digitally controlled Radar Landmass Simulator using PRA techniques. 
Technical Reports on FRA’ s development of radar simulation techniques are 
listed in the bibliography. 

Although a visual simulator creates somewhat different problems, many 
of the basic techniques of radar display synthesis are applicable to it. 
Therefore, MSFC contracted with PRA to develop techniques for real-time 
computer generation of a TV display for NASA’s Lunar Surface Roving Vehicle 
. (LSRV) Simulator. Specifically, the requirement is to: 

(1) devise methods of using hybrid computation of 
signals to complement the images now produced hy 
the present LSRV Simulator using a TV model, and 

(2) devise methods of computing the complete television 
image in real time to obviate the TV model for the 
LSRV Simulator. 


* Throughout this report "hybrid” computation refers to equipment which 
exhibits both analog (or continuous) and digital (on discrete) computing 


properties . 
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The work of the present contract is an initial investigation, 
emphasizing those methods of (l) -which would also he applicable to (2) 
above. This report contains the results of the study and an initial 
recommendation of a system for producing a computer-generated, real-time 
TV display for the LSRV Simulator. 

The remainder of this report is divided into three main sections. 
The first of these is a statement of the data and computational 
req.uirem.ents of a LSRV Simulator. The next section explains the 
techniques which are recommended to compute the required TV signals for 
the simulator in real time . The last section -contains specific methods 
of complementing the present TV display of the LSKV Simulator with 
computer image generation techniques. The Appendix to the report contains 
the results of a recent attempt by PRA to simulate In non-real -time the 
type of TV picture which would be produced by the methods reco mme n de d in 
this report. 



II. SIMULATOR CONCEPTS 


A. Simulator Requirements 

The visual 1 simulator techniques described in this report are 
specifi cally tailored for use in a Lunar Surface Roving Vehicle (ISRV) 
Simulator. They are also adapted to simulating a vehicle which "flies" 
over the lunar surface. The major differences between the visual dis- 
play of a surface vehicle and a "flying" vehicle are the area displayed 
at a given time and the size of the smallest object on the ground which 
is resolvable. It will be seen that the use of the proposed techniques 
allows enough flexibility that the same simulator hardware might be used 
to simulate both types of vehicles or possibly even a combination roving- 
flying vehicle. The requirements of both types of simulator are listed 
below. 


Before going into the technical description of lunar simulator 
techniques, it is appropriate to avoid confusion by defining some of the 
terms which will be used in this report. The term display refers to 
the simulated scene which the "driver" of the vehicle looks at. This 
display is a composite of "display elements" which are calculated by the 
simulator. The nature of the display elements depends on the type of dis- 
play hardware which is used. For example, if a television CRT is used, the 
display elements are the TV sweep waveforms, 500-1,000 per frame. 

When calculating picture elements it is often convenient to 
take a projection on seme reference plane of the scene being viewed. This 
plane is called the view-plane. When discussing the lunar landscape the 
following terms are convenient. "Lunoid" is used to describe the sphere 
having the same radius as the mean radius of the moon. All calculations 
of the lunar landscape are made relative to this sphere. The slow vari- 
ations of the landscape are referred to as the "terrain". Terrain includes 
large mountain ranges, maria, and slow undulations. Lunar "features" are 
the smaller variations of the landscape. Craters, small mountains, rills. 



scarps, are all classed as features. Non- single- value features such as 
rocks are classed as "polyhedral features". A special sub-class of the 
features is designated as "culture" . This class includes man-made objects 
such as landing vehicles, equipment stockpiles, etc. A special character- 
istic of "culture" is its ability to be moved, or added to or deleted from the 
display during the course of a mission. Culture can also have a specular 
or directional light reflection characteristic rather than the almost 
diffuse reflection of the terrain. "Landscape", of course, refers to the 
composite of lunoid, terrain, features, and culture. The total area of 
the lunar surface for which data is stored is referred to as the "problem 
area" . 


The display for the LSRV is to be an "out-the-window" display 
covering 50° horizontal by 30° vertical field of view. When the vehicle 
is on level ground this allows the driver to see no closer than about 
twenty feet, with the horizon appearing to he a little less than 3 statute 
miles distant. High mountains , however , can be seen from much farther. For 
example, a mountain that is a quarter of a mile high can he seen by an 
observer on the surface of the lunoid who is over 30 statute miles away. 

If desirable, the display could also include the more important stars and 
the earth as aids to astronomical navigation. It is important that shadows 
cast by the terrain and features as well ashy .the vehicle itself be Included. 
The very small shadows cast by irregularities in the lunar features are 
taken care of by introducing a "texture" parameter for each of the various 
features . 


Since the display hardware is usually fixed in position relative 
to the driver, it becomes necessary to change the display as the vehicle 
changes its attitude. For example, when the vehicle pitches upward, the 
scene must move down at the proper rate to give the illusion that the 
vehicle is moving. The display can compensate for roll, pitch, and yaw 
without making a completely new calculation of all of the display elements, 
since the relative positions of objects do not change when the attitude is 
changed. Changes in height, latitude, or longitude, however, require that 



all picture elements be recomputed, since in this case the apparent relative 
positions on the view-plane of the objects viewed will change. A flying 
vehicle is capable of the same maneuvers as the roving vehicle, although 
at faster rates. Something should be mentioned here about the rates of 
the various vehicle motions. For a roving vehicle, the maximum lunar 
speed is about 16 ft/sec. and turning rates can be as high as £0°/sec. 

The high maneuverability of the flying vehicle creates speeds an order of 
magnitude higher and turning rates on the order of 5°/sec. The problems 
associated with these rates of motion are more apparent below where c hang es 
in the display associated with these motions are examined. 

B. Data Required to Produce the Display 

From a theoretical point of view, the display is a projection 
of the light reflectivity of the lunar landscape upon the view-plane. For 
convenience in computation this process is looked at in the opposite sense, 
namely, each display element is projected down to the lunar landscape and 
the light reflectivity from that area is used for the intensity of the 
display element. The projection is illustrated in Fig. 1(a).. 

This projection procedure is probably the most complicated job 
of the simulator. It must account not only for changes in vehicle orienta- 
tion, but also for the varying height of the landscape. The varying heights 
cause parts of the distant landscape to be blocked from view or "occluded" 
by nearer portions of the landscape. This problem is shown explicitly 
in Fig. 1 (b) where only part of the landscape is visible (indicated by a 
heavy line). 


The light reflectivity can be either calculated from the com- 
bined landscape data or else separately (and perhaps differently) calcu- 
lated for terrain, features, etc. and the results appropriately superim- 
posed on the display. The most feasible method of accomplishing this 
is discussed below within the context of the total simulator system. 





The light reflectivity is computed from Knowledge of remote 
landscape slope and relative positions of the 'driver and sun. The addition 
of shadows to the reflectivity data is done in two parts, remote shadow 
and local shadow. Fig. 2 should help to distinguish "between the two types 
of shadow. The local shadow is the shadow on the side of a section of the 
landscape away from the sun and the remote shadow is the shadow cast "by an 
object onto a point of the landscape which would not normally be in shadow 
if it were isolated from the rest of the landscape. 

In a more mathematical sense, a point on the landscape is said 
to be in local shadow when the .scalar product of the unit normal vector to 
the landscape at the point with a unit vector to the "sun" from the point 
is greater than zero. A point on the landscape is in remote shadow if 

© it is not in local shadow and 

• a line from the point to the sun intersects the land- 
scape at least once between the point and the sun. 

The reasons for this distinction will become clear when the overall system 
is considered. 

Therefore, it is seen that to produce the display, it is nec- 
essary to know 

• the orientation of the vehicle 

• the projection of the display elements onto the terrain 

® the reflectivity from each part of the terrain. 

The orientation of the vehicle is computed from the slope of the local 
landscape* below the vehicle. The projection of the display elements 
is computed from the vehicle orientation and the height and slope data 
of the remote landscape. Various methods of implementing this calculation 
are ex am ined in Section III .C . below. 

*It is convenient here to distinguish between "local landscape" which influ- 
ences the orientation of the vehicle and "remote landscape" which is visible 
to the driver. 



ft 


The light reflectivity and local shadow are calculated from 
the slope of the remote landscape and the positions of the sun and the 
vehicle. Remote shadow is calculated for the entire problem area before 
each "mission 1 ’ . 

Thus the data needed on hand to compute the display is 
9 vehicle position and local slope 
« remote height and slope data 
e sun position 
e remote shadow data 

Although this seems obvious, it should be kept in mind throughout the 
discussion so that no details are overlooked. It is now appropriate to 
examine the changes which occur in the display data as the image changes. 

C. Changes in Display Data 

As the vehicle moves, and new terrain becomes visible, it is of 
course necessary to replace some of the data used to produce the previous 
frame. Since the landscape data for the entire problem area represented is 
probably too large to be kept in the main computer memory at all times, only 
the data needed for the calculation of the frame at hand can be extracted 
from the complete landscape data bank and put into the computer memory. 
Obviously, much of the -data in the main computer memory from a previous 
frame can be used with some new data, to compute the present frame. An 
efficient means of replacing this relatively small amount of data, while 
keeping the data which, doesn't change, is necessary since the frame rate 
(30 frames/second) is too fast to allow a total replacement from the data 
bank of all the data for each frame. 

The simplest type of vehicle motion is moving forward on level 
terrain. In this case, the distant landscape appears not to change while 



the foreground moves by quickly- Hence, the local height and slope data 
change but the area for which the remote height and slope data are required 
changes only very slowly, even .when the vehicle moves at maximum speed. 

This can be seen in Fig. 3* Notice also that a smaller area is used as 
the vehicle progresses. This is an ideal situation since the same data is 
used repeatedly to calculate successive frames of the display. 

Another good case is when the vehicle pitches. If it pitches 
upward, less of the landscape is seen and no new data must be supplied to 
calculate the display. A downward pitch, on the other hand, introduces a 
need for new data very close to the vehicle. This area (shown dotted in 
Fig. 3) is very small, and might be carried along at all times even when 
it is not used. 

Rolling changes only the orientation of the display relative to 
the display screen and is easily accounted for by a simple coordinate trans- 
formation. Fig. 4 clearly shows this. Again if only a little extra data 
is covered along with the necessary data, no new data will have to be sup- 
plied to generate the display when the vehicle rolls. 

Unfortunately, when the vehicle turns, the data can change 
entirely in very little time. Fig. 3 shows how this happens. Besides 
changing quickly, turning is also different in that the background changes 
most rapidly and the foreground relatively slowly. Thus, rapid change of a 
large volu m e of data can be handled by methods described later in this 
report. The basic idea behind all of the methods is the fact that the 
rapidly c han ging background appears blurred to the driver and therefore 
need not be calculated as precisely as the more slowly changing fore- 
ground. It is also likely that the attention of the driver will be focused 
on the foreground during a turn and the background will go unnoticed. Re- 
gardless of whether the data in the main computer memory must be changed, 
the problem still exists of processing the data in the memory into a dis- 
play at a fast enough rate to avoid flicker and perkiness of the display 
image. Ideally, the display should be completely regenerated with new 
data (updated) at a rate of sixty frames per second. Because of the large 



number of calculations which have to be made it might be difficult or 
impossible to obtain this rate. If this is the case, the frame refresh 
rate could be reduced to thirty per second without introducing flicker 
and the display data update rate could be reduced to as low as ten 
frames per second before the jerkiness becomes objectionable. Since the 
update and refresh rates at which the display can operate depend, of 
course, on the details of the system driving the display, further 
discussion is left to Section III on overall system configuration. 

D . Calculations and Mathematical Models 


It has been shown that it is necessary to know the landscape 
height and slope data to compute the display. The way in which the 
various parts of the landscape are represented is described below. Here 
it is assumed that the required height and slope data is available in 
the computer and the calculation of light reflectivity, shadow, 
occultation, etc. is covered. The way in which these calculations are 
implemented is discussed below in the section on overall system 
configuration. 

The first quantity to be computed is the illumination of the 
terrain by the sun. Lambert's Law states that the illumination of a 
point on a surface Is equal to the intensity of the sunlight times the 
scalar product of a unit normal vector at the point with a unit normal 
vector pointing toward the sun from the point. Since knowledge of the 
terrain slope data is assumed this calculation can easily be made. 

Fig. 5 shows a diagram illustrating Lambert's Law. On the assumption 
that the lunar landscape is a perfectly diffuse reflector of light, the 
light reflectivity from the lunar landscape is simply proportional to 
the illumination, regardless of the orientation of the driver relative to 
the landscape. If, however, the slight specularity of the lunar surface 
Is taken into account, an additional factor multiplied by the illumination 
must be used. This factor is some function of the angle between the line 
of sight to the point on the landscape and the normal vector to the 
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landscape, and also the angle between a unit vector to the sun and the 
normal to the landscape. Fig. 6 illustrates this calculation. Since the 
slope of the landscape and direction of the sun is assumed known at every 
point, it is possible to compute the normal vector to the landscape, the 
vector to the sun, and the vector to the observer. It is assumed from 
here on, however, that no correction is necessary for the slight 
specularity of the landscape. If at any time it is decided to include 
such a correction, it is easy to add. 

The calculation of local shadow is done in exactly the same . 
way. However, if the scalar product of the normal to the landscape with 
the -vector to the sun is found to be negative, then that portion of the 
landscape is known to be in shadow and the intensity is recorded as zero. 

It should be noted that all of the calculations of light reflectivity in 
shadow made up to this point, can be calculated from only a knowledge of 
terrain slope at the point of interest. Remote shadow, on the other hand, 
requires a knowledge of terrain at points other than the point of interest. 
Because of this, it seems wise to •compute all of the remote shadows for a 
given sun position before the start of a mission. The reason for this 
will become clearer when the overall system configuration is described. 

Fig. 7 illustrates how the remote shadow is calculated. A 
profile of the lunar landscape is taken along a section of the landscape 
in a direction parallel to a ray froa the sun. Starting at the edge of the 
section nearest to the sun, the scalar product of the normal to the terrain 
and the vector to the sun is computed. At the point where this quantity 
first becomes less than zero, the height of the terrain is noted. While 
continuing along the section of landscape, the height of the landscape at 
every point is compared to the computed height of a ray from the sun to 
the point at 'which the shadow started. When the difference between these 
heights is equal to zero, the intersection of the ray from the sun with 
terrain has been found. This point is the end of the remote shadow cast 
by the landscape. By repeating this procedure for many cross -sections to 
the landscape the entire area of remote shadow can be computed. The bound- 
aries of this area are stored in the memory of the computer. When the 
final projection of the light reflectivity of the landscape onto the view- 
plane is made, any region which is inside of the stored shadow boundary is 
treated as having zero light reflectivity. 
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The problem of occult at ion is handled in much the same way as 
remote shadow. The main difference is that the sections of landscape are 
made parallel .to a line of sight of the vehicle driver, rather than the 
direction of a ray from the sun. In this case, while moving along a land- 
scape profile, the scalar product of the normal to the landscape with a 
vector toward the driver's eye is taken. When this product becomes less 
than zero, the height of the point is recorded and the intersection of the 
line of sight from the driver * s eye through that point, to the next point 
on the landscape is computed in the same manner as for remote shadow 
above.. This procedure is illustrated in Fig. 8. 

Since not all of the small variations in the landscape can be 
stored in a computer memory, it is necessary to add realism to the display by 
computing some form of texture to be added to the projection of the land- 
scape. This texture can he generated in a pseudo random way which is re- 
produced only while it is visible on the screen. Since variations 
in texture are extremely small, the fact that they are different when 
viewed at some other time, will be insignificant and unnoticeable. The 
reader should also notice that it is necessary to .add this texture only 
in the foreground of the landscape, since at large distances detail this 
fine is not visible. Another method of adding texture is to divide the 
problem area into regions and use the same texture pattern within each 
region. This randomly generated texture could then be stored in a read- 
only memory and used repeatedly. 

E. Display Hardware 

At present raster displays are much superior in writing speed 
to any other type of display. The usual raster formats are: TV raster 

based on a cartesian coordinate system; PPI raster (such as radar) which 
uses polar coordinates; and sonar raster using a spiral sweep. The major 
advantage to raster format is that the beam position is a function of time 
relative to some synchronizing signals so that explicit beam positioning 
data need not be generated. Of thfese formats, TV raster is the most con- 
venient from the standpoint of computation. 
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Displays capable of displaying one million (10^) resolvable 
points in 1/60 second are easily within the present TV technology. 
Digitally driven displays which actually display one point at a time are 
also capable of producing an image with 10^ points. This type of display* 
however* takes several seconds to produce a complete frame — entirely 
too slow for generation of a moving display. A third type of display 
creates an image with vectors or multiple Iissajous figures.. A typical 
vector display can generate one to two thousand vectors in 1 /60 sec . 

Such a picture produced by a thousand or so vectors lacks much of the de- 
tail of a TV raster display. The other disadvantage of the latter two 
display formats is that they require the computer to generate explicit 
beam positioning data as well as intensities. 

TV raster displays are also superior from the standpoint of 
available technology and compatibility. Many types of standard equipments 
for mixing* switching, and storing TV raster signals are readily available. 
In a sense* use of TV raster displays is backed by many years of techno- 
logical development of television techniques. As well as being standard* 
many of the TV equipments mentioned are presently in use in existing simu- 
lators and display systems. 

A specific reason for the use of TV raster format is synchroni- 
zation. The steady and sequential flow of data in a TV raster signal allows 
many operations to be made at the same in synchronism and combined to- 
gether in available video mixing networks. 

The specific type of TV raster display to be used depends on 
the physical setup oi the simulator. The displays can be divided into two 
main types — projected displays and so-called "infinity optics" displays. 
The first type (of which the Eidophor display is an example) sunply projects 
the raster on a screen placed perhaps twenty feet in front of the viewer. 
Thus is far enough way that the driver can focus his eyes at infinity when 
viewing the display. 
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The "infinity optics" displays (such as the several types manu- 
factured by Farrand Optical Company) are placed close to the driver and rely 
on optics to create the illusion of distance and depth. Although the appro- 
priate TV display must be chosen to be compatible with the physical layout 
of the simulator, TV displays all require essentially the same input signals 
intensity and deflection in raster format. 

The only disadvantage of the two displays described above is 
that some type of display sweep memory is needed if the display need not 
be refreshed for every display frame. ' Although new types of displays 
which don't require this are being developed, none are feasible at present. 
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III- OVERALL SYSTEM CONFIGURATION 


A. Data Representation in Storage 

There are several different ways in which the various height and 
slope data can be represented and stored. The more important methods are 
listed below with their advantages and limitations. 


Two-dimensional Polynomial Representation 


With this method, the surface to be represented is divided 
into "regions" within which the variations in the height are neither too 
large nor too numerous. A least squares fit of a polynomial (probably of 
fourth to sixth order) is made to the given terrain data (if actual empirical 
data is used), and the coefficients of the polynomial are stored for each 
region. Under contract to NTDC, PRA has made an extensive study of this 
technique and found that the most feasible way to store the polynomial is 
in terms of the coefficients of the Lagrange polynomial representation. 

For this purpose, the region sizes would probably be chosen as a few 
hundred meters square. It might also be advisable to store the terrain in 
two levels of representation, one having regions several times larger than 
the other. This would reduce the amount of data required to produce the 
profiles of distant parts of the terrain. In addition, height profiles of 
the higher mountains might be stored since at distances much over a mile only 
such height profiles would be visible. The Lagrange polynomial itself is of 
the form: 


h(x,y) 


1 1 2 
= 2 L 2 

i=0 j=0 p=0 


2 ( X ~\\ ( Y ~ Y l\ 

6 ip\ d / S jq. V d / f i+k, j+1, p, q 


where k and 1 define the region, i and j define the corners of the regions 
(see Fig. 9), d is the region size, and p and q determine the order of f. 

The terms g^ and g^ are of the form 

goo(z) = 0 - Z) 3 (1 +3Z + 6z 2 ) 
g Q1 (Z) = (1 - Z) 3 (1 + 3Z) 
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and 


g og (Z) = 1(1 “ *) 3 

g 10 (2) - Z 3 (6Z 2 - 15 Z + 10) 

g n (Z) = Z 3 0 - Z) (33 - 4) 

g 12 (Z) = |Z 3 (1 - 2) 2 


u = i+k 
1 v » j+1 


i+k. j+lj p, q' 


<b 


a p4,1 n 


^ sAt 1 


where 


f. , . , are the stored coefficients. 

H*» 3+3* V, q. 


The derivatives are with respect to u and v rather than 

x and y so that within a region the effective values of x and y are 

normalized to travel from zero to one. This eliminates the necessity of 

using geographic coordinates within a region. In this "modified! 1 form which 

uses derivatives at comer points, the 1 slope of the terrain located at the 

houndary "between regions is continuous across the boundary. Plots of the 

e are shown in Fie. 10. These basis fuunctions are common to all regions, 
rs 

It is interesting to note that Sq^C 2 ) - jg-y (1 “ Z){. This 
symmetry feature will become particularly useful later. 


As a sidelight, the indices p and q. can reach the general values 
of m and n respectively. For the region size described below it ms 
decided that m =» n - a would produce sufficient accuracy for the appli- 
cation at hand. Hence the designation "2-2 version of the modified La- 
grange polynomial". With this the case then, the polynomial itself con- 
tains 36 terms; each term has associated with it a derivative, the order 
of which is the highest combination of p and q.. Hence the cross derivative 


du dv 
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Now instead of storing individual point heights across a region, 
what is stored in the polynomial representation are the 36 derivatives asso- 
ciated with each region. As a convention, 9 are stored at each region comer 
and are arranged such that all of these constants are valid ones for the four 
adjacent regions associated with that corner. Fig. 11 shows pictorially the 
placement of polynomial coefficients at region corners. When applied to the 
appropriate products of the basis functions and then summed, the 36 coeffi- 
cients (stored derivatives) completely characterize the terrain with the region. 

Consider briefly the thirty-six terms of the polynomial itself. 

They can be arranged into four groups of nine terms each; each group cor- 
responds to a region corner. Consider a sweep (straight line) passing 
through a region corner. At any given boundary the only terms in the 
polynomial which contribute to its value at that point are those located 
at the two corners describing the boundary. Hence if a crossing is made 
at x = 0 , y =.5 the only g rg products which are non-zero are those 
which are of the form 

g 0p g 0q ani g 0p 6 lq 

notice that the first subscript of each g corresponds to the appropriate 

rs 

corner designation. In other words is associated with the comer 

(0,0) and g^ g^ is associated with the comer (0,1). See Fig. 9« 

This is to say that at a boundary effectively only half of the terms of the 
polynomial are contributing elements, a characteristic which proves 
to he very important in the implementation of the HPG discussed below. 

2. S pecial Function Representation 

Another type of representation is the special function. 

This is a function which is specifically formulated to represent a certain 
type of feature. It is particularly useful for features which occur fre- 
quently and which are very similar, such as craters, rills, etc., but it is 
also applicable to any single-valued features which are required to look 
smooth and are too small to be included in the terrain representation. The 
special function iB similar to the two dimensional polynomial representa- 
tion except that each feature is treated separately and the parameters are 
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quantities like position, height, diameters, type, etc, rather than poly- 
nomial coefficients. In addition, the ground coordinates of the vertices 
of the rectangle hounding the feature are needed. A special purpose hy- 
brid "feature generator" could then be made to convert these digital par- 
ameters into analog height and light reflectivity "profiles" to be com- 
bined into the video output signal. A classification or representation 
scheme for craters using the technique described above has been developed 
by FRA in an effort coordinated with this project. This method of crater 
representation is described below. Several examples of the type of images 
which can be generated by a computer using this method are shown in the 
Appendix. 


It was decided that the majority of craters can be classed 
into one of three general types. The cross-section along a diameter of 
each of these types is shown in Fig. 12. The mathematical formula 
describing each type is given below. 

The shape of a type one crater of Fig. 12(a) is approximated 
by a circular parabaloid. In terms of the radial distance p from the 
center of the crater the height is given as: 


2 



where: a ~ depth of the crater 

B = shape of crater. 

To put this formula in terms of parameters which are more easily measured 
directly from a map (namely depth, radius, and center coordinate) the 
above formula is converted by using: 

P 2 = (X - X Q ) 2 + (Y - Y Q ) 2 

where (Xq, Y_) is the center coordinate , Since the crater. - 

radius (radius at which the height is zero) is: 

r 1 = 
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this yields: 

(X-Xp) + (y-y q ) 2 1 


within the region where h < 0. 

As can he seen Prom Fig. 12(h) the second type of crater is 
like a type one crater within a radius r, and has a rim of height 6 
inside an annular sector r^ < p < r^. Mathematically, the equation of the 
rim can be written as: 




The complete formula for a type two crater is: 


h 



(X-X Q ) 2 + (Y-Y Q ) 2 


a , 0 < (X-X Q ) 2 + (Y-Y Q ) 2 < r 2 







- r„ 



6 , r 2 < (X-X Q ) 2 + (Y-Y 0 ) 2 <: 


The type three crater illustrated in Fig. 12(c) is singly a 
type two crater with an extended flat bottom. The equation describing a 
type three crater is: 


- a 


</(X-X Q ) 2 + (Y-Y Q ) 2 - ^ 


- .1 


h = 


4 L 


r 2 “ r l 


, 0 < (X-X Q ) 2 + (Y-Y Q ) 2 < r 2 
at,** < (X-X Q ) 2 + (Y-Y Q ) 2 <r 2 




2 7(X-X 0 ) 2 + (Y- Y n ) 2 - r Q ~r 0 \ 2 


3 _2l 


r 3 “ r 2 


6 >r 2 < (X-X Q ) 2 + (Y-Y Q r 


< r 


oj ro 
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3. Polyhedron Representation 

Another useful type of representation is approximation hy a 
polyhedron. The main advantage of this type of representation is that it 
can he used to represent a surface "which is not single valued. This is 
particularly useful for representing rocks and man-made features which 
are not visually single valued. The major limitation is the amount of 
data req uir ed to represent a large or detailed feature. The vertices of 
the pdLyhedron and the unit normal to each face must be stored. This is 
sufficient data to calculate the height and reflectivity profiles* 

Note that the use of polyhedron representations should he 
restricted to convex figures to avoid the "hidden line problem" . It is 
also convenient to assume that the objects represented as polyhedra are 
almost all small enough relative to the terrain that they can be con- 
sidered to be either entirely visible or invisible. This assumption 
greatly simplifies the implementation of the display calculations. Large 
or complex objects represented by polyhedra (e.g., a spacecraft) require 
new techniques not developed at the time of this report. Fig. 13 shows 
a typical rock represented as a polyhedron. 

B. Organization and Operation of the System 

Presented above is the list of data necessary to produce a 
vehicle visual display, the calculations which are made with this data, 
and the way in which the landscape data is represented in storage. How 
the necessary calculations are made on the data in real time by a digitally- 
oriented hybrid computer is now examined. 

A block diagram of the overall simulator system is shown in 
Fig. 1 b. The Digital Processing Unit (DHJ) is the main control and 
storage unit of the simulator. It supplies the necessary data to the 
Terrain Generator (TG), Feature Generator (FG), Shadow Controller (SC), 
Texture Generator (TXG), and Polyhedron Generator (FG) in synchronism 
with each other. The outputs of these various hybrid generators are com- 
bined in the Mixing Unit (MU) to produce a video signal which can he 
applied to a TV display tube. Before going into the details of the 
various system components it is instructive to briefly explain the 
operation of this simulator. 
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At the beginning of a simulated mission,, the DHJ is given the 
initial position of the vehicle, the position of the sun, and the direction 
in which the vehicle is pointing. The DHJ then calculates and stores the 
remote shadow boundaries (previously explained) and the polyhedron reflec- 
tivities (explained below) . The simulator is then ready to proceed with 
the mission. While the mission is underway, the DHJ calculates the vehicle 
attitude from the local height and slope data at the given initial position. 
Based on this information the DHJ next calculates the region of visibility 
for which remote height and slope data is needed. This data is transferred 
into the hybrid generators which produce height and reflectivity analog 
signals for the landscape along the projection of a display element (this 
projection is also a line-of-sight of the driver). These signals are time- 
varying analog voltages whose amplitudes are proportional to height or 
reflectivity at a point on the landscape and whose "time" is proportional 
to the "ground range" of the point along the line-of-sight. 

These synchronized time-varying voltages are combined together 
in the Mixing Unit to produce a composite signal which is the total light 
reflectivity as a function of position on the display plane. This gives 
one complete set of intensities for a TV raster sweep. The process is 
repeated for each sweep until the entire frame is completed. Then the 
data to be sent to the hybrid generators is revised and new display 
element projections are calculated. 

C. Implementation of Calculations 
1 • Landscape Profiles 

It is mentioned above (in Section I.D) that the 
way to avoid the problems of landscape occultation is to calculate along 
landscape sections which are taken parallel to the driver's line-of-sight 
(hereafter such sections are referred to as "landscape profiles"). 

Assuming a TV raster format, this means talking the sweep lines in a 
vertical direction so that the pro j ection| of a display element (raster 
scan) is just one of these landscape profiles. In this way all the calcu- 
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tions are made along each profile, resulting in an intensity vs. time 
signal -which can be applied directly to the TV display. 

When the vehicle rolls, the projection of a display element 
is no longer a true landscape profile. The most straightforward way to avoid 
this problem is to rotate the deflection yoke on the display tube to maintain 
display elements which are true landscape profiles. Since the rate of roll 
is small (a few degrees per second) and the total roll angle never exceeds 
ko° this is quite feasible. Alternatively, the terrain function generator 
could be modified to accept such "rolled” profiles. In any case, this is 
not a serious problem and it is assumed therefore, from hereon, that the 
roll is compensated for and that it is not necessary to consider it further . 

A geared-down stepping motor, directly driven by pulses from the digital 
computer, is as feasible for this purpose as an analog servo. 

2. Organization of the Digital Processing Unit (DHJ) 

A block diagram of the Digital Processing Unit is shown in 
Fig. 15. The DPU is the main control and storage unit for the simulator. 

The Central Processing Unit (CPU) in the DPU is a standard third-generation 
digital computer which is strongly I/O oriented. Besides controlling the 
real-time generation of the display the CPU is used to do the remote shadow 
and polyhedron reflectivity calculations before the start of the mission. 
These data are stored in the respective shadow and polyhedron data banks. 

(See dotted lines in Fig. 15*) 

During the real-time operation of the simulator the CPU 
must perform the following task. At the start of each frame the CPU cal- 
culates which portion of the problem area is visible to the driver. It 
then tells the I/O processors what data they must transfer from their 
respective data banks into their storage buffers to compute the desired 
.landscape profiles. This transfer into buffers is needed since the data 
banks must be very large and therefore probably too slow to transfer the 
necessary data directly into the hybrid generations in real time. Initial 
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considerations suggest that drum storage is the most feasible device for the 
data banks. The CPU also generates control signals which are sent to the 
hybrid generators and Mixing Unit to keep the various hybrid calculations in 
synchronism. 


It is the job of the I/O processors to edit the data trans- 
ferred from the data banks and to order it so that it is ready to be trans- 
ferred to the proper hybrid generator at the instant it is needed. The exact 
allocation of tasks between CPU and I/O processors depends, of course, on 
the specific hardware which is used. For example, if a very powerful CPU 
is used, the job of editing and ordering might be done by the CHJ with a 
corresponding reduction in the sophistication of the I/O processor. 

To allow for features which can change during the course 
of the mission, the CPU merely replaces the data in the data bank describing 
that feature with the changed data. This technique might be useful in 
adding vehicle tracks to the display by storing a small patch of remote 
shadow at each point along the path of the vehicle. 

The data outputs from the DPU which are shown in Figs. l4 
and 15 are as follows: 

1 . Digital Terrain Polynomial Coefficients 

2. Digital Feature Parameters 

3 . Digital Shadow Boundary Data 

k. Digital Polyhedron Vertex and Reflectivity Data 

5, 6. Digital Data and Control Signals for Synchronism 


7. Digital Vehicle Roll Signals 
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3 . Implementation of the Terrain Generator 

Assuming that the proper Bets of polynomial coeffic- 
ients have been assembled by the DPU , the way these coefficients are 
converted into analog height and reflectivity profiles, and ultimately 
into the resultant video signal, can be examined. Generally, the TG 
will compute a height and reflectivity profile by evaluating the height 
and slope of the terrain from the Lagrange polynomials along a projected 
display element . Because of the similarity of the height and reflectivit 
calculations, the height profile generation is described in detail and 
the reflectivity profile technique modeled after it. 

It is most convenient to start the height profile 
calculations from the point directly below the driver's eye, even though 
the first part of this profile will not be used. The angle © n in 
Fig. 16 has previously been calculated, and the origin of the driver's 
eye is known. 


This origin will be within some region (K,L), at a 
"local position" (X 0 ,Y Q ). The local position is always taken relative 
to the size of the region i.e., normalized to the region size. With 
this information, as well as the computed angle © n (shown in Fig. l6) 
of the n th display element projection, the complete equation of the 
line can be written as a parametric equation of the dummy variable t. 
Namely: 


X = Xq + tcos 9 0 < X < 1 

Y = Y Q + tsin 9 0 < Y < 1 

In any other region a similar parametric equation can also be written. 

A typical sweep through a region is illustrated in Fig. 16. 

Consider this region (K,L) with its thirty-six 
associated coefficients as shown in Fig. 17* As long as the sweep Is 
within the region each coefficient is contributing a value to the total 
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height of the surface inside. It is remembered, however, that at any 
boundary only the coefficients located at the corners (points) defining 
that boundary contribute to the value of the polynomial there. Also, 
because coefficients are valid in adjacent regions, the ones which are 
significant during a transition across a boundary can be retained for 
calculation in the next region. 

This clean separation of contributors at a boundary 
is extended to the hardware itself. Examine a network which calculates 
the value of every tern associated with one corner. For the sake of 
example pick the corner (0,1 ), of Fig. l8. The terms which must be 
calculated are products of two basis functions and a coefficient applicable 
to the region: 

SOp g 1q f 0,1,p,q 

The f g,1,p,q i s a constant which is output from the digital computer; 
the g rs are polynomials in x or y which are produced by analog function 
generators . 


Fig. 19 shows the physical layout for calculating 
the values of terms associated with the example corner. Notice that 
only three distinct types of function generator are used; these are 

% ’ g ! ’ e 2 

Consider that a sweep takes time t cos 0 to cross 
the two vertical boundaries of the sample region; it should be noted 
that this time is constant from vertical boundary to vertical boundary . 
Transforming along the x axis the time of the x sweep region crossing 
is t cos 9; the period of the y sweep is t sin 9. The Inputs 
to the function generators are therefore ramps having slopes proportional 
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to cos 9 and sin 9, where 9 is the azimuth of the terrain profile 
being reconstructed. The signal for region boundary crossing (new 
coefficients needed) is one ramp' s value being equal to the maximum 
(a limit stop). Now in order to produce 8 qq( x ), one feeds a g Q 
generator with X(t). Furthermore to give g 1Q (X), one supplies 
X (t) = 1 - X(t) to a g^ generator. This makes use of the symmetry 
property described earlier. 

Hence the entire network consists of twelve function 
generators — three of which are distinct. Three of the function genera- 
tors (g^, g^, gg) are fed X(t); three are fed Y(t); three are fed 
1 - x(t); and three are fed 1 - Y(t). The appropriate outputs are 
multiplied together and then multiplied in a D/A multipier by the 

coefficients f_ . and all 3& terms summed to give height. 

0, 1 , p> q 

The function generators need not be duplicated for 
each corner. Their outputs^ however, must be combined appropriately for the 
other corners to produce the correct combinations of g. ®jq‘ 

Now the system consists of four such multiplying 
matrices all of whose outputs are summed to produce the height profile 
for the sweep. There are 12 function generators, 3 6 analog multipliers, 
and 36 D/A multipliers. The inputs are sawtooths and digital numbers; 
the output is the height profile. 

Consider carefully the boundary that the sweep 
crosses as it leaves the region (See Fig. 18). The values of x and y 
may or may not have reached a maximum; in the case of the present example 
X is at its highest value, 1 . The value then of X(t) must fall to 
zero and new coefficients must be brought in for the new region. At 
present there are two sets of coefficients which could be used, 
namely those associated with the boundary. However they are loaded 
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into the wrong D/A multipliers in the hardware so they must he transferred. 
These two abrupt changes produce undesirable transients in the output which 
cannot be tolerated. 


Now keep the coefficients on the boundary, change 
the ones not on the boundary, and cause the sweep to go backwards. In 
other words instead of a sawtooth wave for X(t), Y(t) there is a 
triangular wave which effectively can be thought of as creating a sweep 
which never leaves a given region. When a boundary is reached, however, 
new coefficients are brought in on the opposite corners and the sweep 
is reversed. The same desired output of height profile is achieved and 
advantages have been gained — 1 ) the inputs to the function generators 
do not have undesirable transients, and 2) the output from the TFG is 
continuous. 


Now continue this thinking with the aid of a drawing 

(See Fig. 20). Consider a region (marked with *) in which a sweep starts. 

1 

Label each corner with a colored dot . As the sweep crosses a boundary 
label the new region with the colors not associated with the boundary. 

Hence pt. 1 would be colored green and pt. 2 would be colored red. Every 
time a boundary is crossed two new corners must be colored and also two 
new sets of coefficients must be brought in. Continue this process for a 
few sweeps. 


Very rapidly one sees an interesting trend (See Fig. 
21). In some horizontal lines there are only red and black dots. In 
alternate horizontal lines there are only green and yellow dots. Similarly 
there are alternate red/green and black/yellow dots in the vertical lines. 
This property has conveniently produced a generalized ordering -scheme for 
retrieving the appropriate coefficients from storage. This will be returned 
to below; now continue the analysis of the colored dot structure. 


^For each of reproduction, the colors in Figs. 21 and 22 are represented by 
letters: B = black; R = red; Y = yellow; G = green. It is suggested that 

the reader fill in the diagrams with actual colors to aid in following the 
description. 
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A very significant fact is that one can determine 
what color the new dots should he when a boundary is crossed. As example, 
consider the waveforms of X(t) and Y(t) 



together with the sweep shown in Fig. 21 . Notice that the point where X(t) 
= 1 corresponds to coloring in a yellow and black set of corners; X(t) = 0 
corresponds to a red and green set, similarly in Y. The following table 
summarizes the possibilities. 


X = 0 

color next dots red and green 

X = 1 

color next dots yellow and black 

Y = 0 

color next dots red and black 

Y = 1 

color next dots green and yellow 


Note the reference to "red and green set" which 
implies partitioning the data into an easily retrievable form. This is 
exactly the case. In storage four arrays (corresponding to red, black, 
green, and yellow) are formed. All that is needed then is a pointer to 
indicate the position in the array. The next "red dot" will be either 1 
in X or 1 in Y away from the pointer. 
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Now return to the hardware. If each corner in the 
multiplying matrix is defined by a color, then it is noticed that only 
red data will be fed into the red corner, only green data into the green 
corner, etc. Therefore, only a switch and three registers need be added 
to each D/A multiplier to completely automate the system. Fig. 22 shows 
this addition. The center register is a holding register. The other two 
load the next values of data corresponding to a boundary reached first in 
X or first in Y. The switch is controlled by the inputs (x(t), Y(t)), and 
it selects which register is to be transferred into the hold register. 

This selection is made according to the same criterion as coloring dots 
before. The table below again summarizes the possibilities. 


Transition 

Corner Selection 

Switch 

0 

11 

transfer red and green 

X First 

X = 1 

transfer yellow and black 

X First 

Y - 0 

transfer red and black 

Y First 

Y - 1 

transfer green and yellow 

Y First 


In addition to transferring, the above table of transitions generates 
interrupts to the computer which tell it to add integer 1 '(in X or I) 
to the appropriate colored array points, which in turn will load the 
appropriate XFIRST and YFIBST registers. Hence the system is completely 
self- structured and requires no previous calculations of region crossings 
or sweep path. 


As an incidental point, the azimuth of the sweep 
referenced to the region boundaries is 9 and is the only calculation 
made, in addition to locating the first region (setting up pointers), at 
the beginning of each sweep. Also the generation of the triangular waves 
is done in an accumulator with a D/A converter with a smoother on the 
output. In this way the sweeps are in sync with the digital computer. 
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Using this same technique the normal vector to the 
terrain at each point within a region can "be computed. The formula for 
the normal vector n is: 



Remember that h = h (x, y) = height of terrain at the local position 
(x, y) within a region. 

A 

n can he obtained directly in terms of polynomial 
coefficients by using time derivatives of Lagrange polynomials since: 


Sh 

dx 


Sh 

Sy 


112 2 

h' = E £ EE 

i=0 p=0 q=0 

112 2 

h* = E EE E 

^ i=0 j=0 p=0 q=0 


8 ip g jq ^ f i+K, j+1, p, q 

% P « frl f i+k, 3 + 1 , P, 1 


Where : 

g^z) = 0-z) 2 (6 + 18 z + 6 z 2 ) 

g^(z) = (1-z) 2 (1 + 8 z + 3 Z 2 ) 

gQ 2 (z) = i (1-z) 2 z (z-2) 
g^ Q (z) = 30 z 2 (z 2 - 2 z + 1) 

gj 1 (z) = z 2 (-15 z 2 + 28 z - 12) 

gj 2 (z) = 2 2 2 O- 2 ) (3-z) • 

and the f. , are the polynomial coefficients, 

i+kjj + l* P, <1 
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If the sun has azimuth angle a (from x-axis) and 
elevation angle e (from horizontal), then the vector to the sun is, frcan 
Fig- 23, 

A A , * A x 

S = Sin e k + cos e (cos a i + sin a ,3 ) • 


Then, assuming that the lunar landscape' is a diffuse 
reflector, the reflectivity r can. he generated from polynomial coeffic- 
ients and sun position data as: 

r(x,y) = (Bin e - h* cos e cos a - h* cos e sin a) [1 + (h’ ) + (h* ) ] 2 


where 


h and h 
x y 


have been defined above as components of terrain slope. 


The entire calculation of r(x, y) is done in a 
hybrid array with the same method as used for. height profiles. Thus the 
output of the TG will be two time varying analog voltages representing 
height and reflectivity respectively. Fig. 2b shows these height and 
reflectivity profiles as functions of time (or ground range) as they 
might come out of the TG together. They are continuous across region boundaries, 
which are thus invisible, as a result of the polynomial representation used. 

Incidentally, if more than one level of terrain 
representation is used (as discussed in Section II. A) the Terrain Gen- 
erator must be -slightly modified. The Modified Terrain Generator (MTG) 
is essentially two single TG's whose outputs are switched to the Mixing 
Unit depending on the ground range of the terrain profile. In this way 
it is necessary to load the high resolution TG only coefficients describing 
the high resolution regions close to the vehicle, thus reducing the total 
number of coefficients which must be transferred for a given sweep, 
sweep. 


4. Implementation of the Feature Generator 

The method for handling features represented by 
special functions (e.g., craters) is similar to the method used to handle 
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the terrain. The Feature Generator (FG) is composed, of a number of sub- 
generators each of which is capable of generating a specific type of 
feature. When the sweep is within the region bounding a certain feature, 
the digital parameters describing that feature are loaded into the appro- 
priate sub-generator within the FG and the x and y analog sweep voltages 
applied to that sub- generator. The output of the sub-generator will be 
two time varying voltages; one representing height vs. ground range and 
the other representing slope vs. ground range. It is thus necessary to 
have a separate type of sub-generator for each type of feature and some 
way of combining the outputs of the individual sub-generators. 

All of the height output voltages are added together 
into a single feature height vs. ground range analog voltage. The slope 
signals are added vect orally to form a vector slope signal which can be 
multiplied (scalar product) by a vector to the sun. This yields a feature 
reflectivity vs. ground range analog voltage. These two voltages are the 
output of the FG to the Mixing Unit. 

There are two ways to organize the FG. The difference 
between them depends on the allocation of computation between the special- 
purpose FG and the DRJ. To reduce the burden on the DFU the features are 
stored and loaded in groups of features inside of regions. These regions 
are conveniently chosen to be the same as the regions used in the terrain 
representation. Using this approach the special purpose equipment must 
have enough sub-generators to take care of all of the features within a 
region or else it must have some digital computing and memory capability 
for loading the correct set of parameters into the correct sub-generator 
at the right time. _ If, on the other hand, the amount of special-purpose 
equipment is to be reduced at the expense of more calculation by the DPU, 
only enough sub-generators need be used to account for any nesting (super- 
position) of features while the DFU calculates when and where to load all 
of the parameters. 


One simplification which can be made in the FG is to 
assume that no two features lie on top of each other. In this case the 
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reflectivity can be computed separately for each feature instead of from 
the composite slope. To allow for small craters on top of other features 
(a frequent occurrence) more than one crater sub-generator could be employed 
and the outputs of these sub- generators appropriately switched to get a 
composite output. 


5 . Implementation of the Shadow Controller 

It is the job of the Shadow Controller (SC) to 
blank the reflectivity signal to insert the remote shadow. The Shadow 
Controller does this by calculating where the sweep crosses the. stored 
remote shadow boundaries and alternately blanking and unblanking the 
sweep. There are two very different ways of implementing this — one 
digital oriented and the other analog oriented. 

In the digital method, the shadow boundaries, stored 
as a sequence of line segments in a digital memory, are loaded by the 
shadow data i/O processor into a hybrid computing unit which computes 
the intersection of the analog sweep input with the line forming the 
shadow boundary. This calculation is made by. putting the line segment 
data (a point, length, and direction along the ground) into an analog 
"line generator" . Referring to Fig. 25, the x component of the sweep is 
fed into the line generator and the corresponding value of y along the 
shadow boundary is the output. When the y component of the shadow 
boundary is equal to the x component of the sweep the lines are inter- 
secting and the reflectivity signal is blanked. It is most likely that 
several of the line generators must be employed so that the order and 
speed with which the digital parameters must be loaded- into line generators 
are less critical. In that case the outputs of all of the line generators 
are combined in an OR gate and then compared with the sweep voltage aB 
explained above. A block diagram of such a controller is shown in Fig. 26. 

Notice that synchronism with the terrain and feature 
generators is guaranteed by the fact that the same sweep voltage is used as 
input to both the generators and the controller. 
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The analog type of Shadow Controller utilizes an 
analog memory such as a scan converter. Here the shadow boundaries are 
written into the analog memory in x, y coordinates and read out along 
the sweep. When a shadow boundary is crossed a pulse comes out of the 
memory and changes the state of the flip-flop which blanks the reflec- 
tivity signal. This method is still synchronized with the other genera- 
tors. However, small errors may result from poor registration of the 
sweep in the memory. 


6. Implementation of the Polyhedron Generator 

It is most convenient to have calculated the light 
reflectivity value of each face of each polyhedron and to have stored 
this value with the polyhedron vertices before the mission is run. This 
is possible assuming diffuse reflection of light from the lunar surface. 
Even if it is decided to include some specularity function in the terrain 
calculations, it could be neglected for features represented as polyhedra 
(hereafter referred to as "polyhedron features"). Assuming this, it is 
possible to compute the reflectivity vs. ground range profile to. be com- 
bined with the other reflectivity profiles. This job is complicated by the 
fact that the intensity Is a double- valued function of ground range. The 
way to account for this is to compute directly the projection of the poly- 
hedron features onto the view plane. This is explained below. 

The projection can be considered in two steps: 

(l ) a transformation of the feature vertices into 
a coordinate system which is fixed relative to 
the vehicle, ami 


(2) a projection from this coordinate system 
onto the display plane. 
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Note that no transformation is made to account for 
vehicle roll since it was previously assumed that this would he accounted 
for hy a stepping motor rotation of the display yoke or seme similar means. 
Fig. 27 shows how the landscape coordinate system is related to the vehicle 
and view plane coordinate systems. 

From this f igure, it can also he seen that : 


• roll is a rotation ( t ) about U ! axis 

• pitch is a rotation ( © ) about the V* axis 

• heading is a rotation ( <j) ) about the W axis 
Notice that with this ordering heading and yaw are the same. 

If each vertex of the feature is stored as a column 


vector 


u. 


v. 

i 




The transformation can be written as a product of two matrices, one 
to account for pitch and the other to account for heading. Notice that 
the standard ordering is always used to avoid errors due to the non-com- 
mutation of the rotations. Thus, the transformed vector is: 


u! " 

i 


cos© 0 sin© 


costj) sinsf> o” 


~ u i~ 


"o' 

v i 

= 

o 

o 


-sinij) cos$ 0 


v i 

+ 

0 



sin© 0 cos© 


0 0 1 


w i 


H 
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If the roll is also to he accounted for in this pro- 
jection it is necessary to multiply the above result. by an additional roll 
matrix: 


1 

0 

0 


0 0 


cosY 

sinY 


sinY 

cosY 


When projected onto the display plane the vertex appears at: 
(x ± ,y 1 ) where x ± = 


These projected points determine the boundaries of 
the various reflectivity values on the display plane. The intersections of 
the reflectivity boundaries with the display sweep are computed digitally 
and converted into an analog signal proportional to the landscape reflec- 
tivity as a function of display plane' position. This signal can then be 
mixed with the reflectivity vs. display plane position signal which is 
stored in the sweep memory. Incidentally, it should be noted that it is 
necessary to project only those features which will he visible to the 
driver. Since the polyhedron features are usually small, such as rocks, it 
can be assumed that these features are either entirely visible or invisible. 
To do this, one may define such a feature to be visible if the point on the 
landscape on which it rests is neither occluded nor shadowed. It 
is necessary to project only those polyhedra which are not too distant 
from the vehicle to he seen. This maximum viewing distance would have to 
be determined from the size of the largest polyhedron. 
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7- Implementation of the Texture Generator 

An inherent property of all the above types of 
approximations to the landscape is that they are smooth and lacKing in 
texture . To give realism to the display it is necessary to add some type 
of texture . This texture is especially important in the foreground of the 
picture where small details can, in practice, be seen by the driver- If 
such small texture is stored for the entire problem area the amount of data 
is enormous and the data rates impossible to provide. The solution to 
this problem is to store one region of a randomly generated texture pattern 
which is symmetric along its edges. This texture can be added directly to 
the reflectivity vs. ground range profile. The texture is added at this 
point so that it has the_ proper perspective when projected onto the display 
plane. Because of the perspective projection and the effects of occultation 
the fact that the texture pattern repeats itself in every region should not 
be noticeable. Bather than actually storing this pattern it is possible to 
generate the pattern in real time from some type of repeatable pseudo- 
random routine. This would eliminate the need for large amounts of texture 

storage but requires a random-function generator that operates at video 
frequencies. 

8* Details of the Mixing Unit 

A block diagram of the Mixing Unit (MU) is shown in 
Pig. 28. The Video Switch (VS) used in the MU is a standard piece of TV 
hardware. Referring to Fig. 2 9, when a signal is applied to the gate input 
G, the threshold detector switches the output from the normally closed 
input C to the normally open input S. The switch stays in this position 
for the duration of the signal at input G, and then returns to input 0. 

The first video switch (VS1 ) .replaces the terrain 
reflectivity signal by the feature reflectivity signal if one is present. 
This corresponds to adding the features "on top of" the terrain. VS2 
blanks the reflectivity signal in the presence of a remote shadow signal 
from the shadow controller. This is simply an addition of the shadow 
"reflectivity" on top of the terrain and feature signal. The texture 
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signal is added to the composite reflectivity signal as a high frequency 
perturbation. The Display Projection Processor (DPP) (explained in detail 
below) calculates the projection of the reflectivity profile onto the 
display plane, thus making it the intensity signal for the TV display 
tube. Since this projection is made at a constant ground range rate, the 

•X- 

display plane rate is discontinuous, making it necessary to store the 
"projected" analog signal until at least one entire raster sweep is 
stored in the Sweep Memory (SM) . At the same time that the projected 
signal is read into- the Sweep Memory, the third video switch (VS3) adds 
the signal from the polyhedron generator. 

9- Sweep Memory 

The Sweep Memory stores the display sweep signals 
before they are sent to the TV tube. If the memory is capable of storing 
the sweep signals for an entire frame, the update rate at which the frames 
are computed can be much less than the display frame rate. One very suit- 
able type of memory is a dual gun cathode ray storage tube or scan 
converter. This accepts the signals from the computer directly and allows 
them to be displayed in any format (e.g., horizontal raster as opposed to 
vertical raster as used in the computer) . An alternative to the scan 
converter is an A/D converter which converts the display sweeps into 
digital form which can be stored in a digital memory such as a magnetic 
disc. This can then be retrieved through a D/A converter and sent to the 
display tube. This has the disadvantage that the read-out raster format 
must be the same as that used by the computer. 

A type of variable- length delay line which might also 
be suitable for an SM is currently under development. The SM poses an in- 
teresting technical problem due to its required speed — equivalent to a TV 
sweep of perhaps 1,000 resolvable points in 3 M-sec. 


^Although discontinuous the signal is still sequential. 
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10. Implementation of the Display Projection Processor 


As its name implies , the Display Projection 
Processor (DDP) forms the projection of the ground-range reflectivity 
profile. onto the display. Fig. 30 illustrates this 'projection. The 
projection process can be looked at as the height data controlling the 
point to which the corresponding reflectivity data is projected. From 
Fig. 30 it is obvious that the elevation angle T| of the line~of -sight 
to a point z on the terrain is given by 


T\(z) 


cot 


z 

H - h(z) 


It should be noted that is .not a single-valued function of the ground 

range z. Using the outlook given above 1] (z) is the angle at which 

the reflectivity r{z) is seen. Because of the non-single -valuedness 

of I] (z) more than one reflectivity can be mapped to any value of Tj . 

If the mapping is taken from the lowest value of z to the highest, 

only the first intensity mapped to any T) is stored. This is how 

oceultation is accounted for. This can be implemented by comparing the 

deriative T| * = ^- 0 zer0i When T] 1 becomes less than zero 

oz 

the reflectivity signal is blanked and the value of 7] at that time is 
stored in a sample and hold amplifier. When 7] (z) returns to the value 
stored, the reflectivity signal is unblanked. If T] is subtracted from 
the pitch angle 9 the resulting 6(z) is the line-of -sight angle 
relative to the center of the view-plane. The y value of the projection 
on the display plane is then given by B tan §(z) = y(z) where D Is 
the distance to the view-plane. If the value of y(z) is used to control 
the vertical sweep position and r(z) is used to control the reflected 
intensity in the sweep memory, the sweep on the screen can be read in 
real time directly from the sweep memory. If this process is repeated 
for each of the sweeps making up the display, the entire picture is 
generated. 
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IV. AUGMENTATION OF THE PRESENT SIMULATOR 


As a way of demonstrating the real-time display generation capabili- 
ties of a digital computer, the below addition of vehicle shadow to the 
present SMK-23 LSRV Simulator is proposed. This technique for adding the 
shadow of the roving vehicle* to the display is very similar to the tech- 
nique used to display polyhedral features in the hybrid system described 
above. The addition of vehicle shadow has the advantage that it can be 
implemented with a small digital computer and readily available video 
hardware . 

Several other improvements to the display have also been con- 
sidered, namely addition of digitally stored features (e.g., vehicle 
tracks) and image enhancement. Any digital image enhancement techniques 
are too slow to operate in real time or else are capable of only the same 
degree of enhancement as contrast and crispening techniques well known in 
television technology. The addition of digitally stored features poses a 
very serious problem, namely occultation of an added feature by terrain 
on the physical model. Since it is not possible to obtain any height data 
from the TV signals, such occultations cannot be computed unless the height 
data of the physical model is also stored digitally. Storing, and processing 
this data would require so much additional equipment that it would be better 
to eliminate the physical model and calculate the entire display. Although 
digital terrain data is also needed for the exact computation of vehicle 
shadow, the approximation method explained below eliminates this need, 
making the addition of vehicle shadow feasible. 

The coordinate systems and rotations used in the calculations are 
described first. Next, the assumptions used in the calculations are 
explained and the mathematics of the transformations presented. Finally, 
two methods of inserting the computer- generated shadow are suggested. 


*It should be noted that this approach is good for any type of vehicle on 
or above any terrain. 
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A. Coordinate Systems and Rotations 

Three coordinate systems are involved in the vehicle shadow 
calculation. One is fixed relative to the terrain. The other two are 
movable with respect to the terrain but fixed relative to the vehicle. 

Fig. 27 shows the relation of these coordinate systems. All of the co- 
ordinate systems are right-handed rectangular cartesian coordinate systems. 

1 . Terrain Coordinate System 

The coordinate axes of the system fixed relative to the 
terrain are defined as- follows: 

• The TJ-axis is from south to north on the terrain 
model. 

« The V-axis is from west to east on the terrain model. 

• The W-axis is from above to below (downward) on the 
terrain model. 

• The Origin is the projection of the Center of the 
Vehicle onto the U-V plane. 

o The Center of the Vehicle is defined to be the 
point about which the vehicle rotates and is 
where the driver's eye is located most of the time. 

2. Vehicle Coordinate System 


The coordinate axes of the system fixed relative to the 


vehicle are defined as follows: 
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• The U ' -axis is from aft to forward on the vehicle . 

• The V 1 -axis is from port to starboard on the vehicle . 

o The W'-axis is from top to bottom (downward) on the 
vehicle . 

• The Origin is the Center of the Vehicle. 

The origin of the vehicle coordinate system is at (0, 0, - H) 
in the terrain coordinate system "H" is the center of the vehicle above 
the ground plane. The ground plane is assumed to be a flat plane. If 
the terrain features are to be taken into account, the terrain coordinate 
system is redefined such that the origin of the vehicle coordinate system 
is (A, B, - H). "(A, B)" is the point on the terrain above which is the 

driver ' s eye . 

3 . View-plane Coordinate System 

The coordinate axes of the view-plane are fixed 
relative to the vehicle and are defined as follows: 

• The X-axis is parallel to the V'-axis of the 
vehicle coordinate system (port to starboard). 

• The Y-axis is parallel to the W'-axis of the 
vehicle coordinate system (top to bottom) . 

• The Origin is forward of the driver's eye at the 
same height in the vehicle as the driver's eye. 
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The origin of the view-plane coordinate system is at (D, 0, 0) 
in the vehicle coordinate system. "D" is the distance of the view-plane 
from the driver’s eye*. It is the U' -coordinate of the origin of the 
view-plane coordinate system. 

If the view-plane is not perpendicular to the fore and aft axis 
of the vehicle, then the vehicle coordinate system should he redefined so 
that the U’-axis is perpendicular to the view-plane. This will simplify 
the notation and calculations. 

4 . Rotations 


The rotations of the vehicle are right-handed rotations 
about the vehicle axes. They are defined by: 

¥ = roll about the U'-axis 

9 = pitch about the V’-axis 

(f> = heading about the W-axis. 

The rotations will always be taken in this order to avoid commutation 
errors. Note that heading and yaw are the same for this ordering. 

5 . Sun Position 


The sun' s position is specified by two angles, e and a, 
in the terrain coordinate system. The angles are defined by: 

e = elevation above the terrain 
O' = azimuth about the z-axis. 


*The view-plane is conveniently chosen as any plane perpendicular to the 
U'-axis at a distance from the driver's eye which 'is less than the distance 
to the nearest point on the ground visible to the driver. Scaling the view- 
plane projection to the actual optical projection screen is accomplished by 
multiplying by the factor 


si 

D 


where D’ is the distance to the optical projection screen. 
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View-plane Projection 


The vehicle view-plane is considered to he parallel to 

the "V-W" plane. 

B. Assumptions in Calculations 

1 . Surface Representing the Terrain 

Methods for storing terrain data in very compact form 
are discussed above. The methods consist of approximating the terrain 
by Lagrange polynomials or polyhedra. Although an accurate portrayal 
of the shadow requires such a knowledge of the terrain it is nonethe- 
less possible to closely approximate the shadow by assuming the terrain 
to be flat. This approximation is unavoidable in an "add on" system for 
generation of the shadow since the effort required to calculate and store 
the terrain data is so great that it warrants the immediate adoption of a 
completely computerized system. That this approximation is appropriate 
can be seen from Fig. 31 * 

Notice that the angle to the shadow’ s edge from the 
view port in the vehicle depends only slightly on the height of the 
terrain on which the shadow falls.* It can also be seen that as the 
distance to the edge of the shadow increases, the difference in angle 
between the actual and calculated lines-of- sight decreases. Since in 
the present vehicles the minimum viewing range is about twenty feet**, 
the areas where the approximation is worst cannot be seen. This error 
can be calculated from the previous diagram using the law of cosines. 


*Since the display is only two dimensional, the angular position is the 
only dimension which the observer sees. 

**This assumes a flat terrain. For an upward sloping terrain the minimum 
range is less, for a downward sloping terrain it is greater. 
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Let: H - height of vehicle 

h = height of view port 

d = distance to shadow’ s edge calculated on flat terrain 
z = height of shadow' s edge above or below the; flat terrain 
Then the angular difference between actual and calculated lines of sight is: 


Assuming typical values; 

H = 10 feet 

h = 5 feet 

z = 2 feet 

and the minimum range: d = 20 feet. 

This gives l/20 radian which is certainly negligible, for demonstration 
purposes*. 


2. Angular Projection 

This calculation is very straightforward. If a small, 
flat plane is assumed, the sun appears in the same position from all 
points on the plane. Thus, the sun position is completely specified by two 
angles. The angles usually given are altitude and azimuth. Notice that 
the azimuth angle given is measured in a clockwise direction from north. 


*This approximation is still applicable to off- the- surface vehicles 
although it is not necessarily as good. 
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If the curvature of the surface must he taken Into account, 
a more complete description must he used. This, however, should not 'he 
needed since the size of the problem area makes this correction negligible. 

One further approximation made is to consider the sun as 
a point. This has the effect of eliminating the penumbral fringe of the 
shadow. This fringe is only 0-5° and should he neglected. If, however, 
it is desired to have the penumbra, it can he calculated or the shadow 
could simply he "smeared" to give the same effect. 

3 • Formulation of the Charact eristic Vehicle Function 


It is easy to construct seme function which characterizes 
a vehicle in some coordinate system which is fixed relative to the vehicle. 
In its roughest form the characteristic function is as set of points in the 
body coordinates which, when connected by straight lines, approximate the 
outline of the vehicle. The limiting case of this is, of course, a con- 
tinuous function describing a closed surface (such as a set of Lagrange 
polynomials). This function depends only on the shape of the vehicle, 
not on time or rotations. Now, the problem is to transform the character- 
istic function to the terrain coordinates, as required for shadow calcu- 
lations. The transformation is described mathematically below. 

C. Mathematical Calculation of the Shadow 
1 . Formation of the Vehicle Function 


For simplicity of calculation a number of ordered points 
connected by line segments are used to characterize the vehicle function. 
This continuous string of line segments should be sufficient to describe 
any solid figure representation of the vehicle including non-convex and 
non- simply-connected ones. 
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To use such a string method it is necessary to also 
have some lines which are not needed to compute the shadow hut are needed 
to keep the string continuous. These lines are eliminated in the final 
display by taking advantage of the notation method. 

Thus, a typical string might look like: a 1 c^, 1, 

a 2 b 2 c 2> °> a 3 b 3 c y ’ " indicatin e that the line from P oint 1 to P° int 
2 is displayed but the line from point 2 to point 3 is not. 

This function is given in the vehicle coordinate system 
and denoted F* . Individual points are denoted by Ff, 1 < i < n. 

2. Transformation of the Vehicle Function 

The first operation is to check the orientation of the 
vehicle relative to the sun to see if any shadow is visible. If not, no 
calculations are done and the program waits for the next frame. If it 
is determined that some shadow is visible, then the following described 
calculations are initiated. 

The vehicle function, F', is transformed point by 
point to the .terrain coordinates. This transformed function is denoted 
by F. This transformation involves a rotation plus a translation. In 
matrix notation: 

F ± = [<J>] (©] [Y] F^ + H 


F. = 
1 



where 
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cos (j) -sin tj) 0 

[(j)] = sin <j> cos i|> 0 

0 0 1 


For convenience we write [R] = [$] [9] then 

F^ = [R] F^ + H 

The matrix transformation of to a set of points describing the shadow 

on the terrain is 



This is illustrated in Fig. 32 
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The shadow point S. is transformed to S’ in the. 

X x 

vehicle coordinates before it is converted to view plane coordinates. 
This is just the inverse of the transformation from vehicle coordinates 
to terrain coordinates. 


S!^ = [R" 1 ] (S ± - H) . 

Since the transformation is linear, orthogonal, and 
unitary: [R** 1 ] = [R] and therefore [R„ ] = [R^l- A 11 ' fc ^ ese 

transformations can be combined, into one which can easily be calculated 
on a digital computer. This transformation is applied to each point of 
the vehicle function F’ . 

From F^ the shadow point S_. can be found in the 
terrain coordinates. Since e and a are known, this is a simple matrix 
mult ipli cation . 


Let 



a 


“d 

= 

b 

and S . = 

e 



1 



c 


o 


then we have: r = - c cot e 

d = a + c cot e cos o' 
e = b + c cot e sin c* 

The complete transformation can be written as a single matrix by writing: 
S!, = [R** 1 ] S 1 - [R -1 1 H 

but S i = [Sj F_j, so by substitution: 
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S ± = [R" 1 ] [S] F. - [R" 1 ] H 

and F i = [R] F^ + H, so by substitution: 

S' = [R" 1 ] [S] ( [R] F! + H) - [r” 1 ] H 

1 1 

By multiplying and factoring the expression can be rearranged", to read as 
follows : 

s*_ = [R" 1 ] [.s] [R] F!^ + [R -1 ] ([S] H - H) 

Letting: C = [R ^3 ([S] H - H), we' get 

S' - [R _1 j [S3 [R] F! + C , and : 

[T] = [R _1 ] [S3 [R], then: 

SI = [T] F! + C . 

x x 

This is a very convenient form since C and [T] are calculated only once 
per frame and [S] is a constant. 

The projection onto the view-plane must be calculated 
and converted to display commands to blank the TV sweep. 

The lines defined by the shadow points can be divided 

into four types. 

(1 ) Entirely Visible - displayed lines that are 
entirely in the positive U’-axis direction. 

(2) Partially Visible - displayed lines that have 
one endpoint with a negative U 1 coordinate . 
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(3) Not Visible - displayed lines that have no points 
within the view-plane at the moment. 

(4) Trace Lines - lines that are never displayed but 
used only to store the lines defining the vehicle 
function. 


These various types are handled as follows; 

(1 ) Display a line between the view-plane projection 
of the endpoints of the line. 

(2) Calculate the point where the line intersects the 
view-plane and connect it to the projection of 
the visible point. 

(3) and ( k } Recognize the type and then ship to the 
next line segment. 


3* View-plane Projection 


Fig. 33(a) ; 


For type 1 points, by ratio and similar triangles in 


X. 

a 

V. 


D_ 

u: 

x 


•and 


X. , 
1-1 

V. 

i-l 


D 

U! , 
1—1 


so 


X. 

1 


D 


V! U' . 
1 1 


and 


i-1 


D 

V! , U! , 
1-1 i-l 


If the side view is examined, the Y-axis replaces the X-axis and the 
W-axis replaces the V-axis in Fig. 33(a) yielding; 
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Y. 

x 

w: 

X 



and 


Vl 

w i-i 


D 



so 


Y. 

x 


D 


WI U! 
x x 


Y i-1 



U. 

x- 


For the projection of type 2 points, Fig. 33(b) yields in the same manner 
as above: 



so 


X. 

x 


D_ 

V! U! 

X X 


V’ - X 
V i-1 i-1 


VI , - VI 
X-1 X 


D - U' 
x-1 

U! - UI , 
X x-1 


so 


X x-1 




D - U i-1 ^ 

U i - U l-1 ] 


If the side view is examined, the Y-axis replaces the X-axis and the W-axis 
replace the V-axis in the above figure and: 



so 


Y. 

x 


D 


W! UI 

X X 


W* 

i-1 


" X i-1 


W l-1 


- WI 
x 


D - U’ 

x-1 • 

UI - UI 1 
x x-1 


so 


X. . 
x-1 


- w i-1 - - M i > 


D - UI , 

x-1 

U! - U* 
x x-1 


To determine the line type calculate if either end- 
point has a coordinate on the U-axis greater than D. If both do not, 
further calculations can be skipped. 


Results of calculations for points which are used more 
than once can be stored for later use if some notation is used to indicate 
such points. For initial test runs, the computer could print out the co- 
ordinates of each point on the view-plane rather than produce a display . 



page 53 


The generation of display command depends on the type of 
display used. The display will have a buffer which is filled while the 
previous frame is being displayed. 

For a non-convex vehicle, a different procedure is used. 
The vehicle is described as a number of convex figures each of which is 
separately put on the view screen. 

All of the line segments of the separate convex figures 
are transformed to the view-plane using the above algorithm. Then the 
outline is calculated as follows. 

The view-plane slope of each line segment is used to 
make this calculation. An array, headed by nodes, is made listing the 
lines going away from that node and the respective angles. The complement 
of each line is also listed. The below procedure is then carried out. 

(1 ) Select the point with the largest y-coordinate 
on the screen. 

(2) Select the smallest angle segment listed for 
that node. 

(3) Store that line segment in memory. 

(h) Store the complement of that line segment. 

( 5 ) Subtract the above angle from each of the 
angles listed for the node -at the other end 
of the segment. 

( 6 ) Return to step (2) until the initial starting 
node is reached. 
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D. Insertion of Vehicle Shadow into the TV Display 

The shadow outline produced by the above procedure can be added 
using various special-purpose equipments. Two of these methods have some 
promi se . 


The first of these methods,, shown in Fig. blanks the TV 
sweep at the appropriate time to produce the correct shadow image on 
the display screen. The second method utilizes a scan converter to 
convert the digital computer output into an analog TV signal which can 
be mixed directly with the existing video signal, as shown in Fig. 35 • 

The first, or synchronized, method relies on explicit calcu- 
lation of the intersection of each TV sweep with the shadow boundaries. 

It uses high-speed D/A converters to provide voltages for comparison with 
the TV deflection signals. 

The second method, although simpler in concept, requires 
specialized TV hardware — a scan conversion system -- to retain the 
shadowed area in view-plane coordinates. The scan converter serves as 
a buffer between the computer and the fixed- rate TV display. 
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FIG. 3- CHANGE IN DATA WITH VEHICLE MOTION 



FIG. 4. - CHANGE IN DATA WITH VEHICLE ROLL 





FIG. 5 - CALCULATION OF LAMBERT'S LAW OF ILLUMINATION 
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FIG. 13 - ILLUSTRATION OF A ROCK AS A POLYHEDRON 
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FIG. 15 - ORGANIZATION OF DIGITAL PROCESSING UNIT (DPU) 
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FIG. 16 - POLYNOMIAL REGIONS 
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FIG. 20 - ORDERING OF THE COEFFICIENTS 
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FIG. 22 - SWITCHING OF COEFFICIENTS 








FIG. 23 - COMPONENTS OF UNIT VECTOR TO SUN 





FIG. 25 - CALCULATION OF SHADOW BOUNDARY CROSSINGS 
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FIG. 26 - DIAGRAM OF DIGITAL ORIENTED SHADOW CONTROLLER 











FIG. 27- RELATIONSHIP OF THE COORDINATE SYSTEMS 



7 



FIG 28- DETAIL OF MIXING UNIT 
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FIG. 31 - VEHICLE SHADOW ON FLAT TERRAIN 
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APPENDIX : 

SIMULATION OF VISUAL DISPLAYS BY 
GENERAL-PURPOSE COMPUTING EQUIPMENT 


In -order to demonstrate the feasibility of creating realistic visual 
simulation of the moon's surface with a digital computer, Pennsylvania 
Research Associates Inc. has developed a Lunar Simulation Program 
(lUNSIM) . This program was run on an IBM 360/65, producing magnetic 
tapes with instructions for a Stromberg-Carlson 4020 Computer -Recorder . 
Several series of photographs were made from the 35 mm positive film 
output of the SC 4020. Three of these sequences appear as Exhibits A, 

B, and C of this report. Although these pictures were not produced in 
real time they nevertheless use many of the same techniques developed 
for a real-time simulator. Of particular importance, is the use of 
conceptual crater generators, or pieces of hardware that implement 
standardized formulas to represent crater shape. 

One of the prime features of the LUNSIM system is that the data for 
the lunar surface is kept in a compressed form. Instead of storing 
heights for every point on the surface LUNSIM takes as input a small 
number of parameters describing craters, which are completely relocatable. 
In a sense, a "crater generator" is included in the program, using ana- 
lytical functions to create surface variations. A description of LUNSIM 
follows . 

LUNSIM is a FORTRAN and Assembly Language program which generates dis- 
play instructions for producing pictures of the moon's surface on the 
SC 4020 Computer-Recorder. The pictures produced are simulated views 
of small portions of the lunar landscape as seen by a landing vehicle . 

A rather simplified model of the moon was created in order to reduce 
the program running time and memory requirements to economically 
feasible amounts. The major features and restrictions of the model are: 
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• The surface is perfectly smooth except where individual 
features (craters) occur. 

• Each individual feature is one of a small number of types 

of features. In the current version of LUNSIM, features are 
three types of craters, all of 'which are symmetrical (i.e., 
the crater height values depend only on the distance from the 
crater center) . 

• The observer (in a landing vehicle) must have an azimuthal 
position on one of the four cardinal points of the compass. 

He may, however, be located over any ground position. 

• Altitude is virtually unlimited and elevation angle can be 
between zero and ninety degrees. The limitation on the verti- 
cal field of view angle is such that the upper line of sight 
does not extend above the horizontal. 

• The sun must be on one of the four cardinal points of the 
compass. The solar elevation angle can be between zero and 
ninety degrees. 

The inputs to the program are of two types: 

• Parameters placing the observer and sun positions and angles 
(known as run parameters). 

• Crater data, consisting of 2 to 5 parameters for each crater, 
describing the type, size, and shape, and the ground coordinates 
of the crater center . 
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The crater data -was obtained by making the appropriate measurements on 
Lunar Map ORB-II-6 (lOO) -which was prepared from Lunar Orbiter II 
photographs. Approximately 400 craters were coded and keypunched for 
a 43 km x 4-3 km square contained with the map . All calculations — 
heights, slopes, intensity returns — are done on a point -by -point 
basis on a cartesian grid. The grid size is a run parameter, limited 
only by the display screen, in this case the 1024 x 1024 plottable 
positions on the SC 4020. 

The following description of LUNSIM refers to the macro-flowchart 
given in Fig . 1 . The operations denoted in blocks 1 -8 of the flow- 
chart are the precalculation stage of the UJNSIM instruction-generating 
process. Since the program was written to accept many combinations of 
observer and sun positions, the logical paths followed by the generalized 
calculation subroutines (blocks 10-15) are set (at block 2) after the run 
parameters are read. 

Various constants (which are functions of the run parameters) are pre- 
calculated next. These constants and all precalculated information are 
communicated to the several subroutines via storage labelled COMMON. 
Having all the information describing the observer's position and 
attitude, the program now determines what portion of the lunar surface 
(map) will be viewed (block 5) . Next the crater data is read in and 
only parameters for craters which fall within the viewed area are 
saved. Two tables are generated, containing these parameters and the 
coordinates of the bounding square for each usable crater- (block 7 ) * 

All calculations are done on a row or column of ground coordinates at 
a time. A special algorithm treats the ’'leading" edge of the area 
which lacks an adjacent row of heights on ora side (block 9) . The 
main loop consists of blocks 10-1 7 . Heights are generated for a row by 
finding which craters are intersected and then evaluating the functions 
for each crater (block 10). Moon curvature compensation i3 made at this 


time also. 
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Slopes in two orthogonal directions are calculated by subtracting height 
values adjacent to a point and dividing by twice the range increment. 
Parallel slopes (block 1 1 } refer to the direction parallel to the 
observer's line of sight and transverse slopes (block 12 ) to those 
perpendicular to the line of sight. The slopes and heights are used 
to find the outward normal to the surface. This in turn defines the 
angle of incidence of the sun's rays. Lambert's Law of Illumination 
is then applied (block 13 ), asstiming perfectly diffuse reflection*. 

The sun calculations are performed moving outwardly from the sun along 
one of the previously generated rows or columns of data, thus causing 
the cardinal point restriction on the sun's position. 

The intensity returns for each point on the row are projected to the 
plane of the observer (block l4). This calculation is done moving from 
far range in towards the observer and automatically accounts for the 
occlusion problem. Also, at this time the projected intensities are 
mapped into appropriate integer Intensity codes for the SC 4020. 

The integer values are transmitted to an Assembly Language subroutine 
(SHOLUB, block 15) which generates the SC 4020 instructions by bit 
shifting, and outputs a block of them each time it is called. An 
algorithm similar to the one for the "leading" edge works on the last 
two rows after the main loop has finished (block 18). The subroutine 
ENLPIC empties the output buffer and closes the output tape (block 19 ). 

t 

Table 1 is a legend for the charts and exhibits which follow. Each 
exhibit is a series of four related pictures generated by LUNSIM . 

Columns 2-9 an d 1 4 of Table 1 are the run parameters for each picture. 
The "viewed area limits" in column 10-1 3 are calculated by LUHSIM and 
are printed as supplementary output. Charts A, B, and C correspond to 
Exhibits A, B, and C, respectively. Each subchart shows the relation- 
ship of the viewed area to the overall working area (the large grid) and 
the position of the observer and the sun for each picture. 


* Obviously other functions of incidence angle could be used, thus 
accounting for different albedo from lunar features of differing 
texture . 
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Exhibit A is a simulated landing sequence with the observer "zeroing in" 
on a predetermined spot on the surface. The first of the series. At, 
is a high-altitude view which encompasses about half the working area 
(nearly 1,000 sq km). Exhibits At and A2 were programmed to produce 
data with higher resolution than the other exhibits. The landi ng 
vehicle moves closer to the surface and the viewing angle is changed 
until, in Exhibit Ah, it is looking straight down at a crater which is 
extremely close to the landing site. 


Exhibit 3 represents a roving sequence. Actually the observer is at 
very low altitude and is looking ahead at a 35° angle of elevation. 

As his ground coordinates are incremented, various surface features 
can be seen to pass beneath him. Chart B shows the movement relative 
to the entire map. 

In the previous two exhibits the sun was arbitrarily positioned to the 
left side of the observer. Exhibit C demonstrates the effects of 
different relative observer and sun locations. In this exhibit 
approximately the same area is viewed in each picture. Notice the 
significant change in shadow when the sun is moved from a position 
perpendicular to the observer to a position opposite the observer. 


The change in picture appearance arises from changing only the sun 
parameters: the crater map used by the computer is identical for 

all twelve pictures . The- reader can realize the power and flexibility 
of this type of digital technique in visual simulation. 
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FIG. I - LUNSIM MACRO -FLOWCHART 
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jJMiitit Humber 


OBSERVER PARAMETERS 


S UH 

PARAMETERS 


VIEWED AREA LIMITS, METERS 
{relative to SW earner of imp ) 


COMMENTS 


< 

h 1 

oJ 

35,000 

43 ! 

30 

10,000 

45 

30 

3,000 

60 

30 

1,000 

90 , 

30 

1,500 

35 

60 

1,500 

35 

60 

1,560 

35 

60 

1,500 

35 

60 

20,000 i 

70 

60 

! 20, 000 j 

70 

60 




20,000 

70 

60 

20,000 

’ j 

70 

PI 


43,825 35,278 512 Landing sequence; touch down 

28,320 28,580 512 at 2t°5'l, Elevation 

22.368 26,704 256 angle changes until view is 

21.368 26,168 256 straight down at low altitude. 


256 Landing vehicle- proceeds east at 

42.245 26,766 256 low altitude (simulates roving)* 

46.245 26,766 256 Observer’s position is incremented 

50.245 26,766 256 4000 m in west -east direction. 


26,947 36,135 256 Effects of varying sun and 

28,127 39,222 256 observer positions relative to 

26,947 36,135 256 one area and to each other. 

39,222 256 
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CHART A (CORRESPONDS TO EXHIBIT A) -LANDING SEQUENCE SHOWN IN EXHIBIT A RELATIVE TO 
ENTIRE WORKING AREA. < DESIGNATES OBSERVER’S POSITION AND VIEWING DIRECTION; 

SHOWS SOLAR POSITION IN RELATION TO VIEWED AREA (HEAVY OUTLINED RECTANGLE), 
CRATER DATA GATHERED ONLY FOR AREA WITHIN MAP AREA SHOWN. FOR A MORE DETAILED 
DESCRIPTION OF THE RUN PARAMETERS WHICH THESE CHARTS REPRESENT SEE TABLE 
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CHART C 


-OBSERVER, SUN, AND VIEWED AREA AS SEEN IN EXHIBIT C. DEMONSTRATES EFFECTS OF 
VARYING OBSERVER AND SUN POSITIONS WITH RESPECT TO A SPECIFIC PORTION OF THE 
LUNAR SURFACE. 
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